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(57) Computer-implemented method, computer 
system and computer program product for creating and 
processing a browser compliant human interface de- 
scription. A predefined application specific human inter- 
face description using application specific layout ele- 
ments (112, 113, 114) is transformed into a standardized 
human interface description using basic layout ele- 
ments (122, 123, 124-1, 124-2, 125, 126, 127). The 
standardized human interface description is decom- 



posed into a human interface layout template and a data 
description. A data instance is instantiated from the data 
description. The data instance is merged with the hu- 
man interface layout template into an individual browser 
compliant human interface description, which is then 
rendered to prompt a user for data input. The received 
data from the user are stored in the data instance. The 
status of at least one layout element is either stored in 
the data instance or in a runtime-copy of the standard- 
ized human interface description. 
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Description 

Field of the Invention 

5 [0001] The present invention generally relates to a human^ interface of a data processing system, and more partic- 
ularly relates to a computer-implemented method and computer system to interact with a computer through automat- 
ically created human interfaces. 

Background of the Invention 

10 

[0002] In prior art systems, human interfaces are described with a standardized human interface description language 
(SIDL). The term "human interface" as used hereinafter, describes any kind of application interface for a human to 
interact with application programs that run on a computer. Examples for human interfaces are graphical user interfaces 
(GUI) or voice user interfaces (VUI). 
is [0003] Typically the SIDL is a "Extensible Markup Language" (XML) based language that provides a set of layout 
components. A layout component comprises description instructions that describe a specific element of the human 
interface. These description instructions are called layout element, hereinafter. A transformer program, comprising 
transformation rules, transforms the layout element into a browser compliant description. 

[0004] A browser, as used hereinafter, is a computer program that "renders" a document which is written in a markup 
20 language, such as "Hyper Text Markup Language" (HTML), "Wireless Markup Language" (WML) or "Voice Extensible 
Markup Language" (VXML), into a visual or audio presentation of this document. A browser can be device specific. 
For example, a browser that renders a HTML document on a personal computer screen differs from a browser that 
renders a WML document on a wireless application protocol (WAP) cell phone display. 

[0005] The browser compliant description can be rendered by a conventional browser into corresponding visual or 
25 audio layout elements on an output device of a computer as part of the human interface. In a SIDL the layout elements 
typically have a an application independent character, such as "row", "cell", "table", "grid", etc. As used hereinafter, 
such layout elements are called basic layout elements. Basic layout elements can be reused in any context of any 
application. 

[0006] However, an application programmer, who wants to create an application specific human interface, desires 
30 to describe this human interface by using descriptive terms that are known in the field of the application. The term 
"application programmer", as used hereinafter, also comprises users that create human interfaces. For example, a 
controller of a company can become an "application programmer" when designing an human interface to capture 
planning data for the next fiscal year from other managers in the company. For example, when Ascribing a survey 
interface, it is convenient to describe the structure of the human interface by using terms like "questionnaire" or "ques- 
35 tion" instead of the previously listed application independent terms. When adding application specific layout elements 
to a SIDL, the SIDL becomes confusing. Many different layout elements result in similar or equal visual layout elements, 
thus overloading the standardized SIDL through redundant application specific layout elements. This redundancy im- 
pedes the application programmer in efficiently identifying an appropriate layout element from an ever growing list of 
layout elements. Further, the transformer program has to be adjusted each time, when a new layout element is added, 
40 because a transformation rule for the new layout element has to be added. This is an inconvenient procedure for the 
SIDL because a standard should not be changed frequently. 

[0007] Further, in the XForms 1 .0 specification (08 June 2001 ) of the World Wide Web Consortium (W3C), the as- 
sumption is made that data information and layout information are separated throughout the whole human interface 
design process. This requires the exact knowledge of the data model that is used in an application. Data model, as 

45 used hereinafter, corresponds to a data description of data that are used (displayed, played, captured, etc.) by the 
human interface. However, there are applications where the data model of the application is not known when the human 
interface design starts. For example, when an application programmer builds a survey application, typically, the infor- 
mation that is to be captured through a survey form (questionnaire) is defined while developing the survey. Input fields 
are added to the form as they are defined during the design process. In general, no data model exists that describes 

so the corresponding data (e.g. dependencies between data, such as the grouping of multiple questions into a question 
group). 

[0008] Further, for example, when a user interacts with a web application (e.g. user submits data) through a human 
interface, the human interface typically is re-rendered in its initial state. Often the layout status of the human interface 
before the interaction is lost because the application does not memorize it. 

55 

Summary of the Invention 

[0009] Hence, the present invention provides method, computer system andcomputer program product to solve the 
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technical problem of providing application specific layout elements and automatically transforming them via standard- 
ized basic layout elements into a browser compliant description language without modifying the standardized basic 
layout elements. 

[0010] For convenience of explanation and without the intention of limiting the present Invention, in the following 
5 description of the present invention it is assumed that the human interface is a graphical user-interface. However, the 
term "layout element" , as used hereinafter to describe a graphical layout element, also has a meaning in a voice human 
interface, where it corresponds to a sequence of sounds (e.g., spoken words) that follows a specific dialogue (inter- 
action) schema. 

[0011] The solution to the technical problem according to a first preferred embodiment of the present invention is 
10 provided by the following characteristics: 

a) A predefined application specific human interface description comprises a plurality of application specific layout 
elements. 

b) A computer system transforms the application specific human interface description into a standardized human 
15 interface description comprising a plurality of basic layout elements 

c) The computer system converts the standardized human interface description into a browser compliant human 
interface description. 

It is an advantage of the present invention that an application programmer gets better control of the application 
human interface development tools of a computer system. The application specific layout elements <ASL£) typically 

20 have a higher degree of abstraction than the basic layout elements (BLE) of the standardized SIDL. This supports 

the process of efficient application specific human interface development because the application programmer 
can use a smaller number of layout elements that are specifically designed for the application. By automating the 
transformation of an application specific interface description language <AIDL) into a browser compliant description 
language (e.g. HTML) of the human interface via a SIDL, the SIDL is not modified. The SIDL is a standardized, 

25 application independent and browser independent format to describe the human interface. Preferably the auto- 

mation is achieved by using a style sheet language transformation, such as "Extensible Style sheet Language 
Transformation" (XSLT). XSLT is a language to transform XML documents into other XML documents. An XSLT 
processor reads a first XML document and follows the instructions in a XSL style sheet, then it outputs a second 
XML document or XML-document fragment. 

30 it is a further advantage of the present invention that the automatically created browsercompliant description 

of the human interface is editable for layout before layout information is separated from data information. This 
allows an application programmer to use standard web authoring toots to refine the automatically created browser 
compliant description of the human interface. 

Further the present invention solves the technical problem of automatically separating data information from 

35 layout information on the basis of a document where layout information and data information is mixed. 

The solution to the technical problem according to the first preferred embodiment of the present invention is 
provided by the following characteristics: 

d) The computer system decomposes the browser compliant human interface description into a human interface 
layout template and a data description. 

40 it is an advantage of the present invention that the inventive computer system automatically creates a data 

model for an application that initially lacks a data model. This is the case when the application is defined through 
an human interface description that includes both, data and layout information. Examples for this kind of applica- 
tions are survey forms or forms for service requests. Survey forms may comprise input or answer fields that are 
defined during the survey design process and where no predefined data description exists. Service requests also 

45 may comprise fields that are not predefined. For example, if a service is not used very often, a predefined data 

description for that service may not exist. 

Further, the present invention solves the technical problem to prompt a user with an human interface after an 
interaction of the user with the computer, wherein the human interface "remembers" its status of before the inter- 
action. "Remember" in this context is used to describe the ability of the inventive computer system to keep the 

so status of a layout element, such as the expansion status of a hierarchy. 

The solution to the technical problem according to the first preferred embodiment of the present invention is 
provided by the following characteristics: The computer system 

e) instantiates a data instance from the data description; 

f) merges the data instance with the human interface layout template into an individual browsercompliant human 
55 interface description; 

g) renders the individual browser compliant human interface description to prompt an user for data input; 

h) receives data from the user; 

i) stores the data in the data instance; and 
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j) stores a status of at (east one layout element. 

Therefore, it is a further advantage of the present invention that the user, upon inputting data through the 
human interface and submitting the data, is prompted with an human interface that shows the same status as 
before the data submission occurred. For example, when the user has expanded a hierarchy to input data that 

5 relate to a certain node of the hierarchy, the expansion status of the hierarchy after data submission remains the 

same as of before data submission. In the first embodiment characteristics a) to d) are processed at design-time, 
whereas characteristics e) to j) are processed at runtime of the computer system. Runtime, as used hereinafter, 
means: occurring while the human interface is executing (being used interactively by a user). Design-time means: 
occurring while the human interface is designed (before being used interactively). 

10 In a second, preferred embodiment of the present invention characteristics c) and d) are replaced by the 

following characteristic: 

k) The computer system decomposes the standardized human interface description into a human interface layout 
template and a data description. 

The advantage is the full automation of the creation of the individual browser compliant human interface de- 
is scription when starting with the application specific human interface description. Because no user interaction occurs 

during the individual browser compliant human interface creation, the second preferred embodiment allows to 
extend runtime processing to comprise characteristics e) to j) and k). Characteristics c) and d) in the first embod- 
iment are executed at design -time. 

20 [0012] At any place in the description of the present invention where a style sheet language transformation, such as 
XSLT, is used to define transformation or conversion rules, alternatively, aperson of skill in the art can implement these 
rules in any programming language, such as Java, as well. 

[0013] The aspects of the invention will be realized and attained by means of the elements and combinations par- 
ticularly pointed out in the appended claims. It is to be understood that both, the foregoing general description and the 
25 following detailed description are exemplary and explanatory only and are not restrictive of the invention as described. 

Brief Description of the Drawings 

[0014] 

30 

FIG. 1 illustrates a simplified block diagram of the inventive computer network system; 

FIG. 2 illustrates simplified flow charts of two embodiments of the inventive method for automatically creating and 

processing a browser compliant human interface description; 
FIG. 3 illustrates details of some method steps; 
35 FIG. 4 illustrates documents that are processed in the inventive method; 

FIG. 5 illustrates further documents that are processed in the inventive method; 
FIG. 6 illustrates ALSEs and BLEs; and 

FIG. 7 illustrates processing of documents and data according to the present invention during runtime. 
40 Detailed Description 

[0015] Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same 
or like parts. For convenience of explanation the reference number table at the end or the description lists the most 
important reference numbers and their descriptions. 
4 5 FIG. 1 illustrates a simplified block diagram of the inventive computer network system 999 having a plurality of com- 
puters 900, 901 , 902 (or 90q, with q=0...Q-1 , Q any number). 

[0016] Computers 900-902 are coupled via inter-computer network 990. Computer 900 comprises processor 910, 
memory 920, bus 930, and, optionally, input device 940 and output device 950 (I/O devices, user interface 960). As 
illustrated, the invention is present by computer program product 100 (CPP), program carrier 970 and program signal 

50 980, collectively "program". 

[0017] In respect to computer 900, computer 901/902 is sometimes referred to as "remote computer", computer 
901/902 is, for example, a server, a router, a peer device or other common network node, and typically comprises many 
or all of the elements described relative to computer 900. Hence, elements 1 00 and 910-980 in computer 900collectively 
illustrate also corresponding elements 1 0q and 91 q-98q (shown for q=0) in computers 90q. 

55 [0018] Computer 900 is, for example, a conventional personal computer (PC), a desktop and hand-held device, a 
multiprocessor computer, a pen computer, a microprocessor-based or programmable consumer electronics, a mini- 
computer, a mainframe computer, a personal mobile computing device, a mobile phone, a portable or stationary per- 
sonal computer, a palmtop computer or the like. 
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[0019] Processor 910 is, for example, a central processing unit (CPU), a micro-controller unit (MCU), digital signal 
processor (DSP), or the like. 

[0020] Memory 920 symbolizes elements that temporarily or permanently store data and instructions. Although mem- 
ory 920 is conveniently illustrated as part of computer 900, memory function can also be implemented in network 990, 

5 in computers 901/902 and in processor 91 0 itself (e.g., cache, register), or elsewhere. Memory 920 can be a read only 
memory (ROM), a random access memory (RAM), or a memory with other access options. Memory 920 is physically 
implemented by computer-readable media, such as, for example: (a) magnetic media, like a hard disk, a floppy disk, 
or other magnetic disk, a tape, a cassette tape; (b) optical media, like optical disk (CD-ROM, digital versatile disk - 
DVD); (c) semiconductor media, like DRAM, SRAM, EPROM, EEPROM, memory stick, or by any other media, like 

w paper. 

[0021] Optionally, memory 920 is distributed across different media. Portions of memory 920 can be removable or 
non-removable. For reading from media and for writing in media, computer 900 uses devices well known in the art 
such as, for example, disk drives, tape drives. 

[0022] Memory 920 stores support modules such as, for example, a basic input output system (BIOS), an operating 
is system (OS), a program library, a compiler, an interpreter, and a text- processing tool. Support modules are commer- 
cially available and can be installed on computer 900 by those of skill in the art. For simplicity, these modules are not 
illustrated. 

[0023] CPP 1 00 comprises program instructions and - optionally - data that cause processor 91 0 to execute method 
steps of the present invention. Method steps are explained with more detail below. In other words, CPP 100 defines 
20 the operation of computer 900 and its interaction in network system 999. For example and without the intention to be 
limiting, CPP 100 can be available as source code in any programming language, and as object code ("binary code") 
in a compiled form. Persons of skill in the art can use CPP 100 in connection with any of the above support modules 
(e.g., compiler, interpreter, operating system); 

[0024] Although CPP 100 is illustrated as being stored in memory 920, CPP 100 can be located elsewhere. CPP 

25 1 00 can also be embodied in carrier 970. 

[0025] Carrier 970 is illustrated outside computer 900. For communicating CPP 1 00 to computer 900, carrier 970 is 
conveniently inserted into input device 940. Carrier 970 is implemented as any computer readable medium, such as 
a medium largely explained above (cf . memory 920). Generally, carrier 970 is an article of manufacture comprising a 
computer readable medium having computer readable program code means embodied therein for executing the meth- 

30 od of the present invention. Further, program signal 980 can also embody computer program 100. ■Signal 980 travels 
on network 990 to computer 900. 

[0026] Having described CPP 100, program carrier 970, and program signal 980 in connection with computer 900 
is convenient. Optionally, program carrier 971/972 (not shown) and program signal 981/982 embody computer program 
product (CPP) 101/102 to be executed by processor 911/912 (not shown) in computers 901/902, respectively. 

35 [0027] input device 940 symbolizes a device that provides data and instructions for processing by computer 900. 
For example, device 940 is a keyboard, a pointing device (e.g., mouse, trackball, cursor direction keys), microphone, 
joystick, game pad, scanner. Although the examples are devices with human interaction, device 940 can also operate 
without human interaction, such as, a wireless receiver (e.g., with satellite dish or terrestrial antenna), a sensor (e.g., 
a thermometer), a counter (e.g., goods counter in a factory). Input device 940 can serve to read carrier 970. 

<o [0028] Output device 950 symbolizes a device that presents instructions and data that have been processed. For 
example, a monitor or a display, (cathode ray tube (CRT), flat panel display, liquid crystal display <LCD), speaker, 
printer, plotter, vibration alert device. Similar as above, output device 950 communicates with the user, but it can also 
communicate with further computers. 

[0029] Input device 940 and output device 950 can be combined to a single device; any device 940 and 950 can be 
45 provided optional. 

[0030] Bus 930 and network 990 provide logical and physical connections by conveying instruction and data signals. 
While connections inside computer 900 are conveniently referred to as "bus 930", connections between computers 
900-902 are referred to as "network 990". Optionally, network 990 comprises gateways beingcomputers that specialize 
in data transmission and protocol conversion. 
50 [0031] Devices 940 and 950 are coupled to computer 900 by bus 930 (as illustrated) or by network 990 (optional). 
While the signals inside computer 900 are mostly electrical signals, the signals in network are electrical, magnetic, 
optical or wireless (radio) signals. 

[0032] Networking environments (as network 990) are commonplace in offices, enterprise-wide computer networks, 
intranets and the internet (i.e. world wide web). The physical distance between a remote computer andcomputer 900 
S5 is not important. Network 990 can be a wired or a wireless network. To name a few network implementations, network 
990 is, for example, a local area network (LAN), a wide area network (WAN), a public switched telephone network 
(PSTN); a Integrated Services Digital Network (ISDN), an infra-red (IR) link, a radio link, like Universal Mobile Tele- 
communications System <UMTS), -Global System for Mobile Communication {GSM), Code Division Multiple Access 
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<CDMA), or satellite link. 

[0033] Transmission protocols and data formats are known, for example, as transmission control protocol/internet 
protocol (TCP/IP), hypertext transfer protocol (HTTP), secure HTTP, wireless application protocol, unique resource 
locator (URL), a unique resource identifier (URI), hyper text markup language HTML, extensible markup language 
5 (XML), extensible hyper text markup language (XHTML), wireless application markup language (WML), etc. 

[0034] Interfaces coupled between the elements are also well known in the art. For simplicity, interfaces are not 
illustrated. An interface cap be, for example, a serial port interface, a parallel port interface, a game port, a universal 
serial bus (USB) interface, an internal or external modem, a video adapter, or a sound card. 

[0035] Computer and program are closely related. As used hereinafter, phrases, such as "the computer provides" 
10 and "the program provides", are convenient abbreviation to express actions by a computer that is controlled by a 
program. 

[0036] it is not important for the present invention, where computer programs, files or documents are stored in com- 
puter system 999. For convenience of explanation, they are stored in memory 920 of computer 900. 
FIG. 2 illustrates simplified flow charts of two embodiments of the inventive computer-implemented method for auto- 

15 matically creating and processing a browser compliant human interface description. 

[0037] The human interface example that is used throughout the detailed description is a survey application example. 
The controller of a company wants to capture financial planning data for the fiscal year 2002 from other managers in 
the company. For this reason, the controller creates a survey questionnaire, comprising various question groups. Each 
question group refers to a specific field, such as "planned costs", or "planned revenues". -Each question group can 

20 comprise various questions. The question used in this example belongs to the question group "planned costs" and 
captures "Planned travel costs 2002 :". Managers prompted with the questionnaire input their planning data next to 
the text of the question and submit the data after having filled in the relevant planning data. 

[0038] All tables with program coding sections that are used in the description are exemplary and explanatory only 
and not intended to provide a fully functional computer program. 
25 [0039] FIG. 2A illustrates a first preferred embodiment of method 400. Method 400 comprises the steps of: 

a) providing 410 predefined application specific human interface description 110 and 

b) transforming 420 application specific human interface description 110 (cf. FIG. 4) into standardized human 
interface description 120. 

30 The first embodiment of method 400 optionally comprises the further steps c) to j): 

c) converting 430 standardized human interface description 120 into a browser compliant human interface descrip- 
tion 130 (cf. FIG. 4). 

d) decomposing 450 browser compliant human interface description 130 into human interface layout template 
140-1 and data description 140-2 (cf. FIG. 5B). 

35 e) instantiating 460 data instance 150 (cf. FIG. 7) from data description 140-2. 

f) merging 470 data instance 150 with human interface layout template 140-1 into individual browser compliant 
human interface description 160 (cf. FIG. 7). 

g) rendering 475 individual browser compliant human interface description 160 to prompt an user (not shown) for 
data input. 

40 h) receiving 480 data 1 70 (cf . FIG. 7) from the user. 

i) storing 485 the data 1 70 in data instance 1 50; and 

j) storing 490 a status of at least one basic layout element 122, 123, 124-1 , 124-2, 125, 126, 127 <cf. FK3. 6). 

[0040] The steps are now explained in detail. 
45 [0041] In the providing step 410, computer system 999 (cf . FIG. 1 ) provides predefined application specific human 
interface description 110. Preferably, predefined application specific human interface description 110 is a markup lan- 
guage description document. 

[0042] Any markup language, such as XML, serves the purpose of defining plurality 111 (cf. FIG. 4) of application 
specific layout elements (ASLE). Table 1 shows typical examples of ASLEs in the context of three specific applications 
so (survey, financial reporting, service request). 



Table 1 : 



examples for applications and their application specific layout elements <ASLEs) 


Application 


ASLEs 


Survey 


questionnaire, questionGroup, question, etc. 


Financial reporting 


incomeStatement, balanceSheet, accountGroup, account, etc. 



6 



EP 1 280 055 A1 



Table 1 : {continued) 



examples for applications and their application specific layout elements <ASL€s) 


Application 


ASLEs 


Service request 


serviceRequestor, service, etc. 



[0043] Table 2 gives an example of XML-code of the survey application specific human interface description using 
the ASLEs questionnaire, questionGroup and question. In the example, the prefix "que:" <cf. table 2) in a tag (<>) 

10 represents a namespace for the application "survey". The following line numbers refer to table 2. The example shows 
a questionnaire 112 (cf. FIG. 6) with a name attribute "survey" (line 2). The questionnaire 112 comprises a question - 
Group 113 with the name attribute "planned_costs" (line 3). The questionGroup 113 comprises a question 114 with the 
name attribute "travel" (line 4). Each name attribute represents a relative data path. In this example, the name attributes 
of the various ASLEs are used to construct a full data path 7/survey/planned_costs/traver from the relative data paths 

is in the name attributes. The full data path becomes part of the data description of the survey application. The full data 
path specifies the storage location of data for question 1 1 4. Using relative data paths allows the application programmer 
to reuse ASLE definitions without adjusting the name attributes. For example, ASLE question 114 can be copied into 
any ASLE questionGroup and the full data path is correctly constructed by concatenating the relative data paths in the 
name attributes of the corresponding ASLEs. 

20 [0044] Optionally, an absolute data path can be used. In this case the name attribute of question 1 1 4 is the full data 
path 7/survey/planned_costs/traver, whereas the name attributes of questionnaire 112 and questionGroup 113 are 
not used for the full data path. Preferably, the data path uses XPath notation, known in the art. 
[0045] XPath (XML Path language) is a language that describes a way to locate and process items in XM L documents 
by using an addressing syntax based on a path through the document's logical structure or hierarchy. The XPath 

25 language is described in the "XPath W3C Recommendation Version 1 .0, November, 1 6 1 999". XPath also allows the 
application programmer to deal with the document at a higher level of abstraction. XPath is a language that is used by 
and specified as part of both, XSLT and XPointer (SML Pointer Language). It uses the information abstraction defined 
in the XML Information Set (Infoset). Since XPath does not use XML syntax itself, it could be used in contexts other 
than those of XML. 

30 



35 



40 



45 
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Line 


Code 


5 


1 


<?xml version=*l , 0 tt encoding= w utf-8 n ?> 




2 


<crue : cruest ionnaire name = " s urvev " 

xmlns :que="http: / /www. sap.com/sapsurvey/ 


10 




Questionnaire'^ 


3 


<que: quest ionGroup name= // planned_costs"> 




4 


< que : Quest: ion name= travel 


15 




LCAU— * XCUlAiiCvl LJ.UVCX Vvi3 wD UU4i • 




s tyle= " inputField" 
visible^" {boolean (//survey/ 


20 




planned_cos t s / travel ) } " 
default="0.0"/> 




5 


</que:question> 




6 


</que : quest ionGroup> 


25 


7 


</que: quest ionnaire> 




Table 


2: application specific human interface 



description document 110 in the survey exampLe 



[0046] The question 1 1 4 has the further attributes text 114-1, style 1 1 4-2, visible 1 1 4-3 and default 1 1 4-4. Text attribute 
114-1 "Planned travel costs 2002 :" indicates the subject of the question to the user. Style attribute 1 1 4-2 "inputField" 
describes a question type, where the answer is written into an input field. An example of another style is "radio Button", 

35 where the user can make a selection from multiple choices by selecting a radio button. Dynamic visible attribute 1 1 4-3 
"{boolean(//survey/planned_costs/travel)}" controls the display of the question. In case a data path "//survey/ 
planned.costs/travel" exists in the data description of the survey application, the question is displayed (visible). Default 
attribute 114-4 assigns the default value "0.0" to the data path of the question. In lines 5-7, closing tags </...> define 
the end of the corresponding ASLE definitions. 

40 [0047] In the transforming step 420, application specific human interface description 1 1 0 is transformed into stand- 
ardized human interface description 120. Preferably, standardized human interface description 120 is a markup lan- 
guage description. Any markup language, such as XML, serves the purpose of defining plurality 121 of basic layout 
elements 122, 123, 124-1, 124-2, 125, 126, 127. Preferably, a style sheet language transformation, such as XSLT, 
executes the transforming step 420 by using transformation rules. Examples of transformation rules in the survey 

45 example are shown in table 3. 

[0048] The following line numbers refer to table 3. Line 1 indicates the start of a XML document. Line 2 indicates the 
start of a XSLT transformation. The "xsl: n prefix indicates a XSLT instruction. The "uicl:" prefix indicates the definition 
of BLEs in SIDL. 

[0049] Line 4 indicates the start of the transformation rule for the ASLE questionnaire 112. The BLE that is matched 
50 with questionnaire 112 is page 127 (line 5). The BLE page 127 comprises other layout elements {line 6). Lines 7 and 
8 close the definition of the questionnaire transformation rule. 

[0050] Line 9 indicates the start of the transformation rule for the ASLE questionGroup 1 13. The BLE that is matched 
with questionGroup 1 1 3 is Grid 1 22 (line 1 0). Grid 1 22 has a number of rows that corresponds to the number of questions 
in questionGroup 113 and two columns (line 10). Line 11 includes further BLEs (e.g. rows) in Grid 122. Lines 12 and 
55 13 close the questionGroup transformation rule. 

[0051] Line 14 indicates the start of the transformation rule for the ASLE question 114 in questionGroup 113. The 
question 114 is transformed into BLE Row 123 (line 15) with two cells 124-1 , 124-2 (BLEs). The row 123 carries a row 
attribute "visible" derived from the question attribute visible 114-3. 
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[0052] BLE Cell 124-1 (line 16) includes BLE TextOutput 126 (line 17). TextOutput 126 is matched with the question 
attribute text 114-1 (line 17). Cell 124-2 (line 19) includes the BLE Fieldlnput 125 (line 22). Fieldlnput 125 is matched 
with the question style attribute 114-2 InputField (line 21 ). Further, the question default attribute 114-4 value is assigned 
to BLE Fieldlnput 125 (line 22). Input data 170 (cf. FIG. 7) received from the user in Fieldlnput 155 are stored under 
5 the corresponding full data path that is constructed by using the relative data paths in the name attributes (lines 23, 
24). Lines 1 8 and 25 to 31 close the transformation rules for the question ASLE. 



IV 


Line 


Code 




1 


< o-ym "I vpr^inn= n 1 O u ^Tif , od.incr= w utf — 8 w 




2 


<xsl : transform version=" 1 . 0" xmlns :xsl= 


15 




M http: //www.w3 .org/iggg/XSL/Transform" 
xmlns :que="http: / /www. sap.com/sapsurvey/ 
ques t ionnaire " 


20 




xmlns :uicl="http: / /www . sap . com/sapsurvey / 
ble"> 




3 




25 


4 


<xsl : template match= w que: questionnaire "> 




5 


<uicl : Page> 




6 


<xsl : apply- templates select=* * */> 


30 


7 


</uicl : Page> 




8 


</xsl : template> 




9 


<xsl : template match=*que:questionGroup*> 


35 


10 


<uicl:Grid name=M&name} tt 
rows=" {count ( . /que .-quest ion) } • cols=*2*> 




11 


<xsl : apply- templates select=* * * 


40 




mode=*<2uestionGroup w /> 




12 


</uicl :Grid> 




13 


</xsl : template> 


45 


14 


<xsl : template match=* que: question" 



55 



9 
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mode=*QuestionGroup" > 


5 


15 


<uicl:Row visible=" {©visible} *> 




16 


<uicl:Cell> 




JL / 


<uicl :TextOutput text=" {©text} " /> 


10 


18 


</uicl :Cell> 




19 


<uicl:Cell> 




20 


<xsl:choose> 


15 


21 


<xs 1 : when 

test="@style=' inputField' "> 


20 


22 


<uicl : Fieldinput 

def ault=" {©default} "> 




23 


<xsl : attribute name = "name "> 


25 


24 


<xsl : call- template 

name = " wr i t e_name_p a t h " / > 


25 


</xsl :attribute> 




26 


</uicl : Fieldlnput> 




27 


</xsl :when> 


30 


28 


</xsl :choose> 




29 


</uicl:Cell> 




30 


</uicl:Row> 


35 


31 


</xsl : template> 




32 


</xsl : trans form> 


40 


Table 


3 : ASLE-to-BLE transformation rules in the survey 



example 



45 [0053] In the survey example, processor 91 0 of computer system 999 (cf . FIG. 1 ) processes table 2 with respect to 
the transformation rules of table 3. The output of this transformation is shown in table 4. Table Corresponds to a XML 
document that describes the same human interface 951 (cf. FIG. 6) as table 2 ^comprising BLEs of plurality 121 instead 
of ASLEs of plurality 111. The BLEs in table 4 are derived from the ASLEs in table 2 via thecorresponding transformation 
rules in table 3. The advantage of this transformation is a standardized, application independent and browser inde- 

so pendent format to describe the human interface 951 . 

[0054] The following line numbers refer to table 4. BLE page 127 is defined in line 2 and closed in line 14. Page 127 
comprises further BLEs. Line 4 describes the BLE Grid 122 that is derived from ASLE questionGroup 113. Grid 122 
in this example has one row and two columns. Grid 1 22 comprises BLE Row 123 that is derived from the ASLE question 
114. Row 123 carries the visible attribute 114-1 (Line 5). Row 123 comprises BLEs 125, 126 (lines 9, 6). BLE 126 is 

55 derived from question text attribute 114-1 (Line 7). BLE 1 25 is derived from question style attribute 11 4-2 (Line 10) and 
default attribute 114-4 stays a default attribute of BLE 125. The full data path for the data of BLE 125 is determined by 
the question transformation rule of table 3. Lines 8 and 11-14 are dosing commands of the corresponding BLE. 
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Line 


Code 


5 


1 


<?xml version=*l . 0* encoding=*utf-8*?> 




2 


<uicl:page id=" survey" 

_ Alltlilb • U--L <^ .1. — 111- *~hr •if WWW • oap • \^\JLUf Sapo IX X. VCy / J^lC 


10 


3 






4 


<uicl:Grid rows = w l n cols="2* id="planned_costs"> 


15 


5 


<uicl:Row visible^' 7 {boolean (//survey/ 

planned_costs / travel ) } " > 




6 


<uicl:Cell> 


20 


7 


<uicl : Text Output text=" Planned travel 

costs 2002 : */> 


8 


</uicl:Cell> 




9 


<uicx:cexi> 


25 


10 


<uici : F ie±cixnput aerauic= u.hj 

name= " / / survey/planned_cos t s / travel * / > 




11 

-1- J. 


</uicl :Cell> 




12 


</uicl:Row> 


30 


13 


</uicl:Grid> 




14 


</uicl :page> 


35 


Table 


4: standardized human interface description 



document 12 0 in the survey example 



40 [0055] In the optional converting step 430, standardized human interface description 120 is converted into browser 
compliant human interface description 130 (cf. FIG. 4). Preferably, browsercompliant human interface description 130 
is a markup language description document. For example, a document for a conventional browser on a personal<:om- 
putercan be written in HTML or XHTML. Preferably, the conversion from standardized human interface description 
document 120 into browser compliant human interface description document 130 is performed via a style sheet lan- 

45 guage transformation, such as XSLT by using appropriate conversion rules. For example, the conversion of XML doc- 
uments into XHTML documents via XSLT is known in the art. Preferably, conversion rules are implemented in asimilar 
way as the transformation rules described in table 3. Preferably, processor 920 applies the conversion rules to stand- 
ardized human interface description document 1 20 and the BLEs are converted into corresponding browsercompliant 
markup language instructions of browsercompliant human interface description document 130. The advantage of the 

so conversion is that the browser compliant human interface description document 130 is editable by a user for further 
refinement of the layout with standard web-authoring tools, such as Microsoft FrontPage or Adobe GoLive. 
[0056] Table 5 illustrates a XHTML document example of browser compliant human interface description 130 in the 
survey example. The standard HTML instructions are not explained in detail as they are known to any person of skill 
in the art. The following line numbers refer to table 5. BLE page 127 (cf. FIG. 6) is converted into lines 1-6 and 22-24, 

55 where line 6 defines an interaction method for the page 127. BLE grid 122 is converted into the table instructions of 
lines 9, 20 having one row 123 (lines 10, 19). Cell 124-1 conversion results in lines 11-13 andcell 124-2 -conversion 
in lines 14-18. The text between the "span" tags in line 12 results from BLE 126 (cf. table 4, line 7). The name attribute 
of the input field instruction (line 16) corresponds to the full data path. 
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Line 


Code 


5 


1 


<ncmi xmins— nctp : / /www. wj . org/ rK/xnunii > 




2 


<head> 




3 




10 


4 


</head> 




5 


/"^ r»»~ 

<Doay> 




6 


<rorm metnocL= pose name= survey > 


15 


7 






8 






9 


<table> 


on 


10 


<tr> 




11 


<td> 




12 


<span>Planned travel costs 2002 :</span> 


25 \ 


1 "3 
lj 


</td> 




14 


<td> 




lO 


<span> 


30 


16 


<input 

name= ■ / / survey /planned_costs / travel " 
type= n text n value= n 0 . 0 " /> 


35 


17 


</ span> 




18 


/ 4_ j ^ 
</tct> 




19 


/ Ui -> 


40 


20 


</table> 




21 






22 


</form> 


45 


23 


</body> 




24 


</html> 



Table 5: browser compliant human interface description 
document 130 in the survey example 

[0057] The input field instruction carries the further attributes type and value. The type attribute "text" results from 
Fieldlnput BLE 125 (cf. table 4, line 10) and the value attribute from the corresponding default value "O.O". 
[0058] In the optional decomposing step 450, computer system 999 extracts human interface layout template 1 40-1 
and data description 1 40-2 <cf . FIG. 5B) from browser compliant human interface description 1 30. As discussed earlier, 
for some applications, such as a survey or a service request, a data description does not exist at the point in time, 
when the human interface 951 (cf. FIG. 6) for the application is described. Therefore, for some applications, browser 
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compliant human interface description document 130comprises a mix of layout information and data description. Pref- 
erably, during runtime the data are separately stored from the layout information. This allows a user specific and ap- 
plication specific instantiation and initialization of data without storing redundant layout information with each data 
instance. Preferably, decomposing step 450 is performed by applying style sheet language transformation, such as 
5 XSLT, to browser compliant human interface description 130. The details of extracting 451 layout template 140-1 and 
extracting 452 data description 140-2 are explained under "FIG. 3B. 

[0059] The further optional steps e) instantiating 460, f) merging 470, g) rendering 475, h) receiving 480 i) storing 
485 the data and j) storing 490 a status are explained in detail under FIG. 7. 

[0060] FIG. 26 illustrates a second, preferred embodiment of method 400. The difference to the first embodiment 
10 {ci FIG. 2A) is the replacement of steps c) and d) (converting standardized description 430 and decomposing browser 
compliant description 450) by step k) decomposing standardized description 440. In the first embodiment the application 
programmer can refine the human interface layout description after step 430 and the decomposing step 450 is executed 
based on the refined layout description (browser compliant human interface description 130). On the other hand, in 
the second embodiment, decomposing step 440 is automatically executed based on the standardized human interface 
is description 120. The automatic human interface creation in this case does not allow the application programmer to 
refine the layout. In the decomposing step 440, computer system 999 extracts human interface layout template 140-1 
and data description 140-2 (cf. FIG. 5A) from standardized human interface description 120. Preferably, decomposing 
step 440 is performed by applying style sheet language transformation, such as XSLT, to standardized human interface 
description 120. The details of extracting 441 layout template 140-1 and extracting 442 data description 140-2 are 
20 explained under FIG. 3A. 

FIG. 3 illustrates details of some method 400 steps. 

[0061] FIG. 3A illustrates sub-steps extracting 441 layout template 140-1 <cf. FIG. 5A) and extracting 442 data de- 
scription 140-2 of decomposing step 440. 

[0062] In the extracting layout template step 441 . computer system 999 processes standardized human interface 
25 description 120 (cf. FIG. 5A), preferably using a style sheet transformation, such as XSLT<cf. table 6), tocreate layout 
template 140-1. 

[0063] For convenience of explanation , table 6 comprises an example of a transformation rule for the BLE Fieldlnput 
125 (cf. table 4, line 10; cf. FIG. 6), because BLE Fieldlnput 125 comprises both, layout information and data. Trans- 
formation rules for other layout elements can be defined accordingly by any person skilled in the art. The following line 
30 numbers without explicit table reference refer to table 6. 
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Line 


/■>■ j 
coae 


5 


1 


<xsl:transform version="1.0" 

xmlns :xsl= n http: //www.w3 . org/ 1999 /XSL /Trans form" 
xmlns :uicl= n http : //www, sap.com/sapsurvey/ble" > 


10 


2 






3 


<xsl : template match= M uicl rFieldlnput n > | 


15 


4 


<input class= M InputField w name=" {©name} w 

type= " text ••> 


5 


<xsl : element name= w xsl :attribute"> 




6 


<xsl : attribute 

name= "name M >value</xsl :attribute> 


20 


n 

1 


<xsl : element name= " xs 1 : value-o f M > 




Q 

o 


<xsl : attribute name= " select "xxsl : value-of 
select="@name n /></xsl :attribute> 


25 


9 


</xsl : element> 




10 


</xsl : element > 




11 


</input> 


30 


12 


</xsl : template> 




13 






14 


< /xs 1 : trans f orm> 


35 


Table 


6: transformation rules for extracting layout 



template 140-1 from standardized human interface 
description 12 0 in the survey example 



[0064] Lines 1, 14 indicate a XSL transformation document. Lines 3, 12 enclose the transformation rule for BLE 
Fieldlnput 125 . Line 4 generates line 11 of target-table 7 when applied to line 10 of source-table 4. Target-table 7 is 
45 a preferred XSLT implementation of layout template 140-1 in the survey example. The data information in the form of 
the default attribute value "0.0" (cf. source-table 4, line 10) is not generated into layout template 140-1 . Layout infor- 
mation is now separated from data. However, a placeholder allows to link to the corresponding data. 
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111 Tic? 




5 


± 


<?xml version=*l . 0* encoding=*utf-8*?> 




Z 


<xsl : transform version="1.0" xmlns:xsl= 

"http://www.w3 .org/1999/XSL/Transform n > 




3 


<xsl : template match="/"> 


10 


A 

"a 


- • - 




c 


<html> 




6 


<form method^' post" name= " survey "> 


15 


7 


<table class= w Grid /r > 




8 


<xsl:if test=" {boolean (//survey/planiied_costs/ 

travel) } »> 


20 


9 


<tr class= tf row"> 




10 


<td><span class= i 'TextOutput' r >Planned 

travel costs 2002 :</spanx/td> 


25 


11 


<tdxinput class="InputField" 

name=" //survey /planned_cost/ 

travel 0 

type=" text "> 


30 


12 


<xsl rat tribute name=" value"> 




13 


<xsl : value-of select= 

' /env : envelope/env : body/ 
survey/planned^costs/travel" /> 


35 


1 A 


< /xs 1 : at tr ibut e> 




ID 


< / inputx / td> 






</tr> 


40 


1 7 


</xsl : if > 




18 






19 


</form> 


45 


20 


</html> 




21 






22 


</xsl : template> 


50 


23 


</xsl : trans form> 



Table 7: layout template document 140-1 in the survey 
example 
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[0065] Lines 5-10 generate the XSL attribute instructions in lines 12, 14 of target-table 7 for the value attribute with 
the "value-of instruction (table 7, line 13). The "value-of" instruction points to the location where the value is stored 
(e.g. data instance 1 50; cf, FIG. 7) and, therefore, provides the link between the separated layout and data information. 
[0066] in the extracting data description step 442, computer system 999 processes standardized human interface 

5 description 120 (cf. FIG. 5A), preferably using a style sheet transformation, such as XSLT, to create data description 
140-2. In the survey example, the XSL transformation processes the XML document in table 4 by scanning the docu- 
ment for name attributes. €ach time a name attribute having data path information is detected, corresponding tags 
(<data_path_element>, </data _path_element>) are inserted foreach data path element into data description document 
140-2 (cf. table 8). Preferably, data description document 140-2 is written in a markup language, such as XML. The 

10 name attribute 7/survey/planned_costs/travel" is detected in line 10 of table 4. The resulting data description 140-2 
document in the survey example is shown in table 8. The following line numbers refer to table 8. Line 1 indicates a 
XML document. Lines 2-4 define the data path 7/survey/planned_costs/traver of default value "0.0" (line 4). The closing 
tags </...> (lines 4 to 6) complete the definition of the data path. 

15 



25 



Line 


Code 


1 


< ?xml version= tt l . 0* encoding^ utf -8 * ?> 


2 


<survey> 


3 


<planned_costs> 


4 


<travel>0 . 0</travel> 


5 


< /planned_cos t s > 


6 


</survey> 



30 Table 8: data description document 140-2 in the suarvey 
example 

[0067] FIG. 3B illustrates sub-steps extracting 451 layout template 140-1 <cf. FIG. 5A) and extracting 452 data de- 

35 scription 140-2 of decomposing step 450. 

[0068] In the extracting layout template step 451 , computer system 999 processes browser compliant human inter- 
face description 130 (cf. FIG. 5B), preferably using a style sheet transformation, such as XSLT, to create layout template 
140-1 . Table 9 illustrates, for the survey example, transformation rules that transform browser-compliant human inter- 
face description 130 (cf. source-table 5) into layout template 1 04-1 (cf. target-table 7). For convenience of explanation, 

40 table 9 comprises a example of a transformation rule for the input field instruction (cf . table 5, line 16), because the 
input field instruction comprises both, layout information and data. Transformation rules for other layout elements can 
be defined accordingly by any person skilled in the art. The following line numbers without explicit table reference refer 
to table 9. 

[0069] Line 1 indicates the start of a XSLT document. Lines 3, 13 indicate that the comprised coding applies to the 
45 input field instruction of source-table 5 (cf. table 5, line 16). Lines 4, 12 copy the input field instruction of source-table 
5 resulting in lines 1 1 , 1 5 of target-table 7. Line 5 copies all source-table attributes except value attributes. Therefore, 
line 1 1 of target-table 7 has no value attribute. Layout information is now separated from data. However, a placeholder 
allows to link to the corresponding data. Therefore, lines 6-11 generate XSL instructions for the value attribute into 
lines 12-14 of target-table 7. Lines 6, 7, 11 generate an attribute instruction for the value attribute (of the input field 
so instruction) in lines 12, 14 of target-table 7. Lines 8-10 generate line 13 of target-table 7 that comprises a "value-of" 
instruction to retrieve the eliminated data from the corresponding location in data instance 150. 
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Line 


Code 


5 


1 


<?xml version=*l . 0" encodings w utf -8 * ?> 
<xsl : transform version= M 1.0" 

xmlns : xs 1 = " h t tp : / /www . w3 . org / 1 9 9 9 /XSL / Tr ans f orm n > 


10 


2 




3 


1 <xsl : template match= M input "> 




4 


<xsl:copy> 


15 


5 


<xsl:copy-of select= tt @* [nameO 

!= 1 value 1 ] n /> 




6 


<xsl : element name= "xsl : attribute "> 


20 


7 


<xsl : attribute 

name= " name " > value< /xsl : attribute> 




8 ! 


<xsl: element name= n xsl : value-of "> 


25 


9 


<xsl : attribute 

name= n select tt > / <xs 1 : value-of 
select="@name" /></xsl : attribute> 




10 


</xsl :element> 




11 


</xsl : element > 


30 


12 


</xsl:copy> 




13 


</xsl : template> 




14 


• • • 


35 


15 


< /xs 1 : trans f orm> 



Table 9: transformation rules for extracting layout 
template 140-1 from browser compliant human interface 
description 130 in the survey example 



45 [0070] In the extracting data description step 462, computer system 999 processes standardized human interface 
description 130 (cf. FIG. 5B), preferably using a style sheet transformation, such as XSLT, to create data description 
140-2. 

[0071] In the survey example, the XSL transformation processes the XHTML document in table 5 by scanning the 
document for name attributes. Each time a name attribute having data path information is detected, corresponding 
so tags for each data path element (<data_path_element>, </data_path_element>) of the data path inforamtion are in- 
serted into data description document 1 40-2 (cf . table 8). The name attribute 7survey/planned_costs/trave^ , is detected 
in line 16 of table 5. The resulting data description 140-2 document in the survey example is shown in table 8 and 
already explained under FIG. 3A. 

[0072] Layout template 140-1 and data description 1 40-2 are equivalent to the corresponding documents described 
55 under FIG. 3A. In the survey example, the documents described in tables 7 and 8 arecreated. 

FIG. 4 illustrates documents 110, 120 and 130 that are processed 420, 430 in the inventive method 400. 

[0073] Predefined application specific human interface description 1 1 0 comprises plurality 11 1 of application specif ic 

layout elements 112, 113, 114 (cf. FIG. 6). Preferably, the ASL€s are described in a markup language, such as XML 
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<cf.Table2). 

[0074] Computer system 999 applies transformation rules for ASLE-to-BLE transformation (cf . table 3) to application 
specific human interface description 110 to transform 420 it into standardized human interface description 120.Stand- 
ardized human interface description 120 comprises plurality 120 of basic layout elements 122, 123, 154-1 , 124-2, 155, 
s 1 26 and 1 27. Preferably, the BLEs are described in a markup language, such as XML (cf . Table 4) and the transformation 
is a style sheet language transformation, such as XSLT. ^ 

[0075] Optionally, computer system 999 applies conversion rules to standardized human interface description 120 
to convert 430 it into browser compliant human interface description 1 30. Browser compliant human interface descrip- 
tion 1 30 is editable with conventional web authoring tools, such as Microsoft FrontPage or Adobe GoLive. For example, 

10 browser compliant human interface description 130 is a markup language document (e.g. XHTML), where all BLE 
elements are converted into markup language instructions (e.g. XHTML instructions) that can be rendered by acon- 
ventional browser (cf. table 5). Preferably, the conversion is a style sheet language transformation, such as XSLT that 
converts XML statements into XHTML instructions, which is known in the art. 
FIG. 5 illustrates further documents 140-1 , 140-2 that are processed in method 400. 

15 [0076] FIG. 5A illustrates decomposing 440 standardized human interface 120 into layout template 140-1 and data 
description 140-2. Transformation rules for extracting 441 layout template 140-1 are described in detail in table 6. 
Extracting 442 data description 140-2 is described in detail under FIG. 3A. 

[0077] FIG. 5B illustrates decomposing 450 browser compliant human interface description 130 into layout template 
140-1 and data description 140-2. Extracting 451 layout template 140-1 is described in detail in table 9. Extracting 442 
20 data description 140-2 is described in detail under FIG. 3B. 

FIG. 6 illustrates ALSEs 112, 113, 114 and BLEs 122, 123, 124-1 , 124-2, 125, 126 and 127. ALEs are shown with solid 
lines and BLEs with dashed lines. 

[0078] The human interface description is first described with ALSEs. In the survey example the ASLEs questionnaire 
112, questionGroup 113 and question 114 are used. The ASLEs reflect the logical structure of human interface 951 
25 where questionnaire 112 comprises at least one questionGroup 113 and questionGroup 113 comprises at least one 
question 114. Question 114 has attributes, such as attributes 114-1 to 114-4. For example, human interface 951 is 
displayed on output device 950 (cf. FIG. 1). 

[0079] BLEs in a SIDL typically have a application independent or graphical character, such as page 127, grid 1 22, 
row 1 23 or cell 1 24-1 , 1 24-2. Different types of data, such as TextOutput field 1 26 or inputField 1 25, can be assigned 
so to acell. A cell can even comprise af urther grid that comprises further rows and cells, wherein radio buttons, checkboxes 
or any other data type gets assigned to the cell. Therefore, the generic nature of BLEs allows to compose any kind of 
application specific human interface 951 . 

[0080] The present invention provides method 400 {cf. FIG. 2) to automatically transform the logically structured 
ASLEs 112, 113, 114 into the graphically structured BLEs 122, 123, 124-1 , 124-2, 125, 126, 127. The assignments of 
35 BLEs to ASLEs are described as transformation rules (cf. description of FIG. 2, table 3). In the survey example the 
following assignments of table 10 are defined in the transformation rules of table 3: 



Table 10: 



ASLE-to-BLE assignments in the survey example 


ASLE 


BLE 


questionnaire 112 


page 127 


questionGroup 113 (with n questions) 


grid 122 (with n rows and 2 cells) 


question 114 with attribute "visible" 114-3 


row 123 of grid 1 22 (with 2<;ells 1 24-1 , 124-2) with row attribute 
"visible" 


question attribute "text" 114-1 


"TextOutput" 126 


question attribute "style" 114-2 (value=lnputField) 


"Fieldlnput" 125 


question attribute "default" 114-4 


attribute "default" of BLE 125 



FIG. 7 illustrates processing of documents 140-1, 140-2, 150, 1«0 (optional 120-1) and data 170 according to the 
present invention during runtime. Document 120-1 is a runtime copy of standardized user interface description 120. 
[0081 ] In a preferred embodiment of the present invention, computer system 999 (cf . FIG 1 ) executes the remaining, 
optional steps of method 400 (cf . FIG. 2) during runtime : 



e) instantiating 460 data instance 150 from data description 140-2. 
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f) merging 470 data instance 150 with human interface layout template 140-1 into individual browser compliant 
human interface description 160. 

g) rendering 475 (cf. FIG. 2) individual browser<;ompliant human interface description 160 to prompt an user (not 
shown) for data input. 

5 h) receiving 480 data 1 70 from the user. 

i) storing 485 the data 1 70 in data instance 150; and 

j) storing 490 a status of at least one basic layout element (122, 123, 124-1 , 124-2, 125, 126, 127). 

[0082] In the instantiating step 460, computer system 999 complements data description 140-2 by further, runtime 
10 dependent data (data that are created or modified during runtime) resulting in data instance 150. examples for runtime 
dependent data are user name, document creation date, session ID, error messages, etc. Preferably, data instance 
150 is a markup language document, such as an XML document. The following line numbers refer to table 1 1 . In the 
survey example, table 11 illustrates an envelope (lines 2, 1 3) comprising the runtime dependent data user name 
("USER1", line 4) in its header (lines 3, 5), whereas the data description (lines 7-11) forms its body (lines 6, 12). The 
is envelope name space is represented by the prefix "env:". 



20 


Line 


Code 




1 


<?xml versions* 1 . 0* encodings "utf- 8 * ?> 


25 


2 


<env : envel ope 

xmlns : env="http: / /www . sap . com/sapsurvey/env" > 




3 


<env : header> 




4 


<env : user>USERl< /env : user> 


30 


5 


< / env : header > 




6 


<env : body> 




7 


< survey > 


35 


8 


<planned_costs> 


9 


<travel>0 - 0</travel> 




10 


< /planned_cos ts 


40 


11 


</ survey > 


12 


< /env: body > 




13 


</env: envel ope> 


45 


Table 


11: data instance document 150 in the survey 



example 



so [0083] In the merging step 470, layout template 140-1 is applied to data instance 150. Preferably, this corresponds 
to a style sheet transformation (cf. table 7) of data instance 150. 

[0084] If required, data instance 150 is modified, for example, by an application program {e.g. computer program 
101 on computer 901), prior to applying layout template 140-1. This is achieved through interface 155. For example, 
computer system 999 (cf . FIG. 1 ) transfers data of data instance 1 50 (e.g. on computer 900) to the application program 
55 through interface 155 and data instance 150 receives modified data from the application program through interface 
155. The advantage is an application specific initialization of data instance 150. For example, in the survey example 
a user (e.g. USER1 , cf. table 11 , line 4) wants to input the planned travel costs for the next fiscal year. The default 
value that is derived from the corresponding data description 140-2 is M 0.0 M (cf. table 11, line 9). In the example, the 
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application program knows the real travel cost of the user for the previous fiscal year. The application program is called 
through interface 1 55 and runs a query for the previous travel cost. The result value is returned to data instance 1 50 
through interface 155 and replaces the old default value. 

[0085] Table 1 2 shows individual browser compliant human interface description document 1150 as result of merging 
5 step 470. Preferably, document 1 60 is written in a markup language, such as XHTML. The following line numbers refer 
to table 12. Document 160 is similar to the document 130 instable 5. The differences in lines 4 and 10 are explained 
in detail in the storing status step 490. In line 1 9 of the survey example, layout information (input) and data from data 
instance 1 50 (default value "0.0") are merged when lines 1 1 -1 5 of table 7 (layout template 1 40-1 ) are applied to table 
11 (data instance 150). 

10 





Line 


Code 


15 


1 


<?xml version="l . 0 W encoding= w utf-8*?> 
<html xmlns = "http: //wvjw.w3 .org/TR/xhtmll "> 




2 


<head> 


20 
25 


3 


• • • 


4 


<! — Functions (e.g. JavaScript) : 

a) set cursor on page display 

b) determine cursor position on page submission 
— > 




5 






6 


</head> 


30 


7 


<body> 




8 


<form method= n post" name= " survey rt > 




9 




35 







40 



45 



50 



55 
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5 


10 


< input type hidden narae="//env: envelope/ 

env : states /uicl : page/@cursorPos " 
vaiue= / / survey /p.LannecL_costs / travel / > 


10 


li 




12 






13 






14 


<td> 


15 


15 


<span>Planned travel costs 2002 :</span> 




16 


</td> 




17 


<td> 


20 


18 


<span> 




19 


<input name=" //survey /planned_costs/ 

travel u type= n text " value= 11 0 . 0 " /> 


25 


20 


< / span> 




21 


< / to 




22 




30 


23 


</table> 




24 






25 


</ f orm> 


35 


26 


</body> 




27 


</html> 



Table 12: individual browser compliant human interface 

40 

description document 160 in the survey example 



[0086] In rendering step 475 (cf. FIG. 2) individual browser compliant human interface description 160 is rendered 
45 by a conventional browser, for example on output device 950 (cf . FIG. 1 ). In the survey example, the user is prompted 
with a screen that has a structure similar to the BLEs shown in FIG. 6 -(dashed lines). The user reads the question text 
in TextOutput BLE 126 and is expected to input data in FieldJnput BLE 125, where a default value is displayed. If more 
than one question is displayed, the user can perform more than one data input. After having finished all data inputs, 
the user submits the data 170. For example submission of data is performed by clicking an appropriate button on 
so human interface 951 or by selecting an "ENTER" key on input device 940 (cf. FIG. 1). 

[0087] In the receiving data step 480, a computer of computer system 999 (e.g. computer 900, cf . FIG. 1 ) receives 
the data 1 70 from the user via user interface 960 (cf . FIG 1 ). Data 1 70 comprise at least one data set. Preferably, data 
170 are received in a format that comprises a name and a value for each data set of data 170. Preferably, the name 
of each data set is a XPath that is compliant with data instance 150 and indicates the storage location of thecorre- 
55 sponding value of the data set. Table 1 3 illustrates data 1 70 in the survey example. Each row of table 1 3 corresponds 
to a data set of data 1 70. 
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Table 13: 



format of data 1 70 in the survey example 


Name 


Value 


//survey/planned_costs/travel 


5000 







io [0088] In the storing data step 485, the data 170 are stored in data instance 150 at the corresponding location. In 
the survey example, the storage location is implicitly known from the name column of table 13 (e.g. "//survey/ 
planned__costs/lraver). Optionally, after having stored the data 1 70, the data 1 70 can be processed by an application 
program (not shown) by using interface 1 55, similar to the description of the merging step 470 . 
[0089] In the storing status step 490, the status of at least one basic layout element (122, 123, 124-1 , 124-2, 125, 

15 126, 127) is stored in data instance 150. Alternatively, the status can be stored in runtime copy 120-1 of standardized 
human interface description 120 (dashed lines). 

[0090] The status of a basic layout element comprises information about the layout element at the point in time when 
the user submits data 1 70. For example, if the user expanded a hierarchy while interacting through the human interface 
951 , the expansion status of the hierarchy is stored. In the survey example, the status of BLE page 1 27 is the position 

20 of a cursor on human interface 951 (cf. FIG. 6). In case, the user inputs data into more than one BLE Fieldlnput, the 
cursor typically stays in the BLE that received the last data input. For convenience of -explanation, only BLE Fieldlnput 
125 is considered. In this case, the status u cursorPos n of BLE page 127 is a unique pointer to the BLE 125. Such a 
pointer can be implemented as a unique ID for each BLE. In the survey example, the data path "/survey/plan ned_costs/ 
travel" serves as unique ID for BLE Fieldlnput 125. Assuming that the cursor is in BLE 125 when the user submits data 

25 1 70, for example, the status cursorPos=7survey/planned_costs/travel n of page 1 27 is set in a hidden field of individual 
browser compliant human interface description 1 60. In the survey example of table 1 2 <document 1 60) this is achieved 
by using a function (e.g. a JavaScript function) (cf . table 12, line 4b) that determines thecursor position and by line 10 
of table 1 2 that transfers the cursor position into a further field instruction of document 1 60. Preferably, the further input 
field instruction is for a hidden input field. Thecontent of the further input field instruction is part of data 1 70. The name 

30 attribute 7/env:envelope/env:states/uicl:page/@cursorPos" corresponds to a "stateMocation (<env:envelope> <env: 
statesxuicl:page ... cursorPos=...>; cf. table 14, line 6) in data instance 150, where value=7/survey/planned_costs/ 
travel" is stored as value attribute cursorPos (cf. table 14, line 7). When individual browser compliant human interface 
description 160 is re-generated after the submission of data 170, a further function of document 160 (cf. table 12, line 
4a) is executed that retrieves the BLE page 1 27 status information from data instance 150 and sets the cursor position 

35 accordingly. 



40 
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Line 


Code 


5 


1 


< rxnix version— j. • u encouing- uc l o . ^ 




2 


<env : envelope 

xmlns :env="http: / /www. sap . com/sapsurvey/env w > 


10 


3 


<env:header> 


4 


• • • . 




c 


</ env : header > 


15 


£1 
O 


<env:states> 


*7 
1 


<uicl:page id="survey ff 
cur sorPos = " / 7 survey /planned_cos ts / travel " 
xmlns : uicl^http : / /www. sap . com/sapsurvey/ 


20 




V>1 /">■ 




8 






9 


</env:states> 


25 


1 0 


<env:body> 




11 






12 


</env:body> 


30 


13 


</env : envelope> 




Table 


14: data instance document 150 after having 



stored a layout element status 

35 



[0091] In an alternative, preferred embodiment of the present invention, the BLE status can be stored in runtime 
copy 120-1 of standardized user interface description 120. This alternative embodiment works when the second pre- 
ferred embodiment of the present invention is used, where method 400 steps 430, 450 are replaced by step 440. This 
40 implies the expansion of the runtime environment from method steps 460-490 (cf. FIG. 2) to further comprise method 
step 440. In this case, using the survey example, BLE status information in data 1 70 is stored directly in runtime copy 
120-1 (cf. table 15, line 2). The status information is preserved during steps decomposing 440, instantiating 460 and 
merging 470, so that the status is set when rendering 475 human interface 951 at least a second time. 

45 



50 



55 
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Line 


Code 


5 


1 


<?xml version= n 1 . 0 * encodings w utf- 8 w ?> 


10 


2 


<uicl:page id= 0 survey" 

cursorPos= * / /survey /planned__cos ts /travel 99 

yth! nc 'Hi rT = ff hft*n» / /ukajw -o^o ythti / cflriQiirvPv/ 

ysj.m_iio • U. X l. L — 11 U L- \J . / / WWW ■ Od£-/ • 1^»1U / OdJJO LA J- V / 

bleV> 




3 






4 


<uicl:Grid rows="l w cols= n 2" id="planned_costs"> 


15 


5 


<uicl :Row vis ible=" {boolean (//survey/ 

planned_costs/ travel) } "> 




6 


<uicl:Cell> 


on 


7 


<uicl :TextOutput text=" Planned travel 

COStS A\j\jZ :"/> 




8 


</uici xeii> 


25 


9 






10 


name= " / /survey/planned_costs / travel * /> 


30 


11 


</uicl :Cell> 




12 


</uicl:Row> 




13 


</uicl:Grid> 




14 


</uicl :page> 


35 


Table 


15: runtime copy 120-1 of standardized human 



interface description document 120 in the survey 
example, including status information. 



Having described the present invention as computer-implemented method 400 the invention is now described as com- 
50 puter system 999. 

The inventive computer system 999 automatically creates and processes a human interface description. 
[0092] It is assumed that computer 900 (cf . FIG. 1 ) is the operating computer. A person of skill in the art can implement 
the invention also in a client-server system, where a server computer (e.g. computer 901 ,cf. FIG. 1) is used for data 
processing and a client computer (e.g. computer 900, cf . FIG. 1 ) serves as a front-end computer with a browser. 
55 a first preferred embodiment of computer system 999 comprises the following means: 

a) a means for providing 410 (cf. FIG. 2) predefined application specific human interface description 110 {cf. FIG. 
4); and 
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f 

b) a means for transforming 420 (cf. FIG. 2) application specific human interface description 1 1 0 into standardized 
human interface description 120 {cf. FIG. 4). 

Preferably, means a) comprises a markup language document 110, such as XML (cf. table 2), that further 
comprises a plurality 111 of ASLEs 112, 113, 114 (cf. FIG. 6). Application specific human interface description 
5 document 1 1 0, preferably, is stored in memory 920 (cf . FIG. 1 ) of computer 900. 

Preferably, means b) comprises a set of transformation rules to transform ASLEs 112, 113, 114 into BLEs 122, 
123, 124-1 , 124-2, 125, 126, 127 (cf. FIG. 6) of standardized human interface description 120: For example, the 
transformation rules are implemented as style sheet language transformation documents (cf . table 3) and stored 
in memory 920. Standardized human interface description 120, preferably, is implemented as a markup language 
w document (cf. table 4) and is also stored in memory 920. Processor 910 processes the transformation rules and 

applies them to application specific human interface description document 110. 

Optionally, in a first preferred embodiment, computer system 999 further comprises means c) to j). The optional 
means are now explained in detail: 

c) a means for converting 430 (cf. FIG. 2) the standardized human interface description 120 into a browser corn- 
's pliant human interface description 130 (cf. FIG. 4). Preferably, computer 910 converts document 120 by applying 

a set ofconversion rules that convert BLEs 122, 123, 124-1, 124-2, 125, 126, 127 of document 120 into instructions 
of a browser compliant markup language of document 130. Preferably, processor 120 executes the conversion 
when processing a style sheet language transformation comprising the conversion rules. Resulting document 130 
is stored in memory 920. 

20 d) a means for decomposing 450 (cf. FIG. 2) browser compliant human interface description 130 into human 

interface layout template 140-1 (cf. FIG. 5) and data description 140-2 (cf. FIG. 5). Means d), preferably comprises 
two style sheet language transformation documents that are applied to document 130 to extract layout template 
140-1 and data description 140-2. An example for the style sheet transformation document to extract layout tem- 
plate 1 40-1 is given in table 9. Preferably, data template 1 40-1 is a style sheet language transformation document. 

25 The style sheet language transformation document to extract data description 140-2 is described in the detailed 

description of FIG. 3B. Preferably, processor 910 processes the two style sheet language transformation docu- 
ments and stores the resulting documents 140-1 and 140-2 in memory 920. In this first preferred embodiment of 
computer system 999 a design-time memory portion of memory 920 is used because the decomposing step 450 
occurs during design-time of human interface 951 (cf. FIG 6). 

30 e) a means for instantiating 460 (cf. FIG. 2) data instance 150 (cf. FIG. 7) from data description 140-2; 

f) a means for merging 470 (cf . FIG. 2) data instance 1 50 with human interface layout template 1 40-1 into individual 
browser compliant human interface description 160 (cf. FK3. 7); 

g) a means for rendering 475 (cf. FIG. 2) individual browser compliant human interface description 1 60 to prompt 
an user for data input; 

35 h) a means for receiving 480 (cf. FIG. 2) data 1 70 (cf. FIG. 7) from the user; 

i) a means for storing 485 (cf . FIG. 2) data 1 70 in data instance 150; and 

j) a means for storing 490 (cf. FIG. 2) a status of at least one basic layout element 122, 123, 124-1 , 154-2, 125, 
126, 127. 

40 [0093] Preferably, means e) comprises a computer program that reads data description 1 40-2 from memory 920 and 
creates data instance document 1 50 in a runtime portion of memory 920 (e.g. a RAM for storing runtime data) by adding 
runtime dependent data to the data of data description 140-2. Runtime dependent data are created or modified, e.g. 
by an application program (e.g. 101 on computer 901 ,cf. FIG. 1 description), during runtime. Table 11 shows an example 
of data instance 150, which is implemented as a markup language document. 

45 [0094] Preferably, means f) comprises layout template 1 40-1 , which is a style sheet language transformation docu- 
ment (cf. table 7) in the example. Processor 910 reads layout template 140-1 from memory 920 and applies it to data 
instance 150. The result is individual browser compliant human interface description 160 (cf. XHTML example in table 
12), which is a markup language document that is stored in a runtime portion of memory 920. 

[0095] Preferably, means g) comprises a conventional browser program (not shown), such as the Microsoft internet 
so Explorer or the Netscape Navigator, executed by a processor of a computer (e.g. processor 910 of computer 900). 
The browser renders browser compliant human interface description 160 and displays the result as human interface 
951 on output device 950. Preferably, the human interface 951 prompts a user to input data 170 (cf. FIG. 7) through 
the human interface 951 . The user inputs data via input device 940 (cf . FIG. 1 ). For example, the user selects a displayed 
input field in the human interface 951 via a mouse device and enters data via a keyboard. 
55 [0096] Preferably, means h) comprises the browser and the basic input/output system (BIOS) of computer 900. The 
BIOS is receiving signals from input device 940 via bus 930 (cf . FIG. 1 ). The signals are interpreted as characters and 
are appropriately displayed by the browser on display device 950. Upon submission of data 170 by the user (e.g. by 
clicking a submit button with the mouse device), computer 900 receives data 170 via ^us 930. 



25 



EP 1 280 055 A1 

[0097] Preferably, means i) is implemented by using a data 1 70 format according to table 1 3 and a storage program. 
The storage program automatically stores the data 1 70 in the runtime memory portion of memory 920 that belongs to 
data instance 150. The exact storage address is derived from the XPath in the name of each data set of table 1 3. 
[0098] Preferably, means j) is implemented by using JavaScript functions and a hidden field in document 160 <cf. 
5 Table 12). A JavaScript function determines the status of at least one basic layout element 122, 123, 124-1 , 124-2, 
125, 126, 127 and stores the status in the hidden field. The hidden field becomes part of submitted data 170 and is 
stored by the storage program in data instance 150 (cf. table 1 4, line 7) together with other data sets of data 1 70. Like 
other data sets of data 170, the status also comprises a name with the XPath that corresponds to the exact storage 
address. 

10 [0099] In a second preferred embodiment of computer system 999 optional means c) and d) are replaced by optional 
means k) for decomposing 440 standardized human interface description 120 into human interface layout template 
140-1 and a data description 140-2. Preferably, means k) is implemented as two style sheet language transformation 
documents that are applied to document 120 to extract layout template 140-1 and data description 140-2. An example 
for the style sheet transformation document to extract layout template 1 40-1 is given in table 6. Preferably, data template 

15 1 40-1 is a style sheet language transformation document. The style sheet language transformation document to extract 
data description 1 40-2 is described in the detailed description of FIG. 3A. Preferably, processor 91 0 processes the two 
style sheet language transformation documents and stores the resulting documents 140-1 and 140-2 in memory 920. 
In this second preferred embodiment of computer system 999 a design-time memory portion of memory 920 is used 
because the decomposing step 450 occurs during design-time of human interface 951 (cf. FIG 6). 

20 [0100] In an alternative preferred embodiment of computer system 999, runtime processing is extended to further 
comprise means b) and k). To achieve this, computer system 999 creates a runtime copy 120-1 (cf. FIG. 7) of stand- 
ardized human interface description 120 as a further part of means b). Preferably, runtime copy 120-1 is stored in a 
runtime memory portion of memory 920. In this case, the decomposing means k) accesses runtime copy 120-1 instead 
of document 120 to extract layout template 140-1 and data description 140-2, which are both also stored in a runtime 

25 memory portion of memory 920. In this alternative embodiment, means j) stores 490 the at least one status data set 
of data 170 in runtime copy 120-1 instead of data instance 150 (cf. dashed lines in FIG. 7; table 15, line 2). The 
decomposing means k) then extracts the status data into data description 140-2 and creates a corresponding link in 
layout template 1 40-1 . 

[0101] Having described the present invention as computer implemented method 400 and computer system 999, it 
30 js now described as a computer program product 100 (cf. FIG. 1) that can be stored on a computer readable data 
carrier 970 (cf. FIG. 1). 

[0102] Computer program product 100 has a plurality of instructions for causing a processor (e.g. processor 91 0) of 
a computer (e.g. computer 900) to create and process a human interface description. Computer program product 100 
causes computer 900 to execute the following steps: 

35 

a) providing 410 predefined application specific human interface description 110; and 

b) transforming 420 application specific human interface description 110 into standardized human interface de- 
scription 120. 

In a first preferred embodiment, computer program product 100 causes computer 900 to execute the further 
*o optional steps c) to j): 

c) converting 430 standardized human interface description 120 into browser compliant human interface descrip- 
tion 130; 

d) decomposing 450 browser compliant human interface description 130 into human interface layout template 
140-1 and data description 140-2; 

45 e) instantiating 460 data instance 150 from data description 140-2; 

f) merging 470 data instance 150 with human interface layout template 140-1 into individual browser compliant 
human interface description 160; 

g) rendering 475 individual browser compliant human interface description 1 60 to prompt an user for data input; 

h) receiving 480 data 1 70 from the user; 

so i) storing 485 data 1 70 in data instance 150; and 

j) storing 490 a status of at least one basic layout element 122, 123, 124-1 , 124-2, 125, 126, 127. 

Computer program 1 00 steps a) to j) are equivalent to method 400 steps a) to j), respectively, that are described 
in detail under FIGS. 2, 3 and 7. 

In a second preferred embodiment, computer program product 1 00 causes computer 900 to execute optional 
55 step k) instead of steps c) and d): 

k) decomposing 440 standardized human interface description 120 into human interface layout template 140-1 
and data description 1 40-2. 
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[0103] Computer program 100 step k) is equivalent to method 400 step k) described in detail under FIGS. 2 and 3. 
[01 04] Each of the embodiments of computer program product 1 00 can be stored on computer readable data carrier 
(e.g. data carrier 970). 
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50 

Claims 

1. A computer-implemented method (400) for creating and processing a human interface description; the method 
(400) comprising the steps of: 

55 

providing (410) a predefined application specific human interface description (110); and 
transforming (420) the application specific human interface description (110) into a standardized human inter- 
face description (1 20). 
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2. The method (400) of claim 1 , wherein the predefined application specific human interface description (110) is a 
markup language description using a plurality (111) of application specific layout elements (112, 113, 114). 

3. The method (400) of claim 1 , wherein the standardized human interface description (120) is a markup language 
5 description using a plurality (121) of basic layout elements (122, 123, 124-1 , 124-2, 125, 126, 127). 

4. The method (400) of claim 1 , wherein the transforming step (420) uses a transformation program in a programming 
language. 

w 5. The method (400) of claim 4, wherein the transformation program is a style sheet language transformation. 

6. The method (400) of claim 1 comprising the further step: 

converting (430) the standardized human interface description (120) into a browser compliant human interface 
is description (130). 

7. The method (400) of claim 6, wherein the browser compliant human interface description (130) is a markup lan- 
guage description. 

20 8. The method (400) of claim 6, wherein the converting step (430) uses a conversion program in a programming 
language. 

9. The method (400) of claim 8, wherein the conversion program is a style sheet language transformation. 

25 10. The method (400) of claim 1 , comprising the further step: 

decomposing (440) the standardized human interface description (1 20) into a human interface layout template 
(140-1) and a data description (140-2). 

30 11. The method (400) of claim 10, wherein the decomposing step (440) comprises the following steps: 

extracting (441) the human interface layout template (140-1) from the standardized human interface descrip- 
tion (120); and 

extracting (442) the data description (140-2) from the standardized human interface description (120). 

35 

12. The method (400) of claim 1 1 , wherein the extracting steps (441 , 442) use a transformation program in a program- 
ming language; 

13. The method (400) of claim 12, wherein the transformation program is a style sheet language transformation. 

40 

14. The method (400) of claim 6, comprising the further step: 

decomposing (450) the browser compliant human interface description (130) into a human interface layout 
template (140-1) and a data description (140-2). 

45 

15. The method (400) of claim 14, wherein the decomposing step (450) comprises the following steps: 

extracting (451) the human interface layout template (140-1) from the browser compliant human interface 
description (130); and 

so extracting (452) the data description (140-2) from the browser compliant human interface description (130). 

16. The method (400) of claim 1 5, wherein the extracting steps (451 , 452) use a transformation program in a program- 
ming language. 

55 17. The method (400) of claim 16, wherein the transformation program is a style sheet language transformation. 
18. The method of claim 14, comprising the further steps: 
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instantiating {460) a data instance (1 50) from the data description (1 40-2); 

merging (470) the data instance (150) with the human interface layout template {140-1) into an individual 
browser compliant human interface description (160); 

rendering (475) the individual browser compliant human interface description (1 60) to prompt an user for data 
5 input; 

receiving (480) data (1 70) from the user; 

storing (485) the data (170) in the data instance {150); and 

storing (490) a status of at least one basic layout element (122, 123, 124-1 , 124-2, 125, 126, 127). 

10 19. The method (400) of claim 18, wherein the merging step (470) uses a transformation program in a programming 
language. 

20. The method (400) of claim 19, wherein the transformation program is a style sheet language transformation. 
15 21. The method of claim 18, wherein in the receiving step (480), the data (170) comprise a XPath. 

22. The method of claim 10, comprising the further steps: 

instantiating (460) a data instance (150) from the data description (140-2); 
20 merging (470) the data instance (150) with the human interface layout template (140-1) into an individual 

browser compliant human interface description (160); 

rendering (475) the individual browser compliant human interface description (160) to prompt an user fordata 
input; 

receiving (480) data (1 70) from the user; 
25 storing (485) the data (1 70) in the data instance (150); and 

storing (490) a status of at least one basic layout element (122, 123, 124-1 , 124-2, 125, 126, 127). 

23. The method (400) of claim 22, wherein the merging step (470) uses a transformation program in a programming 
language. 

30 

24. The method (400) of claim 23, wherein the transformation program is a style sheet language transformation. 

25. The method of claim 22, wherein in the receiving step (480), the data (170) comprise a XPath. 

35 26. A computer system (999) for creating and processing a human interface description; the-computer system 4999) 
comprising: 

a means for providing (410) a predefined application specific human interface description -(110); and 
a means for transforming (420) the application specific human interface description {1 1 0) into a standardized 
40 human interface description (120). 

27. The computer system (999) of claim 26, further comprising: 

a means for converting (430) the standardized human interface description (120) into a browser compliant 
45 human interface description (130). 

28. The computer system (999) of claim 27, further comprising: 

a means for decomposing (450) the browser compliant human interface description (130) into a human inter- 
50 face layout template (140-1) and a data description (140-2). 

29. The computer system (999) of claim 28, further comprising: 

a means for instantiating (460) a data instance (150) from the data description {140-2); 
55 a means for merging (470) the data instance (150) with the human interface layout template (140-1) into an 

individual browser compliant human interface description (160); 

a means for rendering (475) the individual browser compliant human interface description {160) to prompt an 
user for data input; 
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a means for receiving (480) data (170) from the user; 

a means for storing (485) the data (170) in the data instance (150); and 

a means for storing (490) a status of at least one basic layout element (122, 123, 124-1 , 124-2, 125, 126, 127). 

30. The computer system (999) of claim 26, further comprising: 

a means for decomposing (440) the standardized human interface description (120) into a human interface 
layout template (1 40-1 ) and a data description (1 40-2). 

31. The computer system (999) of claim 30, further comprising: 

a means for instantiating (460) a data instance (150) from the data description (140-2); 

a means for merging (470) the data instance (150) with the human interface layout template (140-1 ) into an 

individual browser compliant human interface description (1 60); 

a means for rendering (475) the individual browser compliant human interface description (160) to prompt an 
user for data input; 

a means for receiving (480) data (170) from the user; 

a means for storing (485) the data (1 70) in the data instance (150); and 

a means forstoring (490) a status of at least one basic layout element (122, 123, 124-1 , 124-2, 125, 126, 127). 

32. A computer program product (100) having a plurality of instructions for causing a processor-(910) of a computer 
(900) to create and process a human interface description; the computer program product (1 00) causing the com- 
puter (900) to execute the following steps: 

providing (410) a predefined application specific human interface description (110); and 
transforming (420) the application specific human interface description (110) into a standardized human inter- 
face description (1 20) 

33. The computer program product (1 00) of claim 32, causing the computer (900) to execute the further step: 

converting (430) the standardized human interface description (1 20) into a browser corhpliant human interface 
description (130). 

34. The computer program product (100) of claim 33, causing thecomputer-(900) to execute the further step: 

decomposing (450) the browser compliant human interface description (130) into a human interface layout 
template (140-1) and a data description (140-2). 

35. The computer program product (100) of claim 34, causing the computer (900) to execute the further steps: 

instantiating (460) a data instance (150) from the data description (1 40-2); 

merging (470) the data instance (150) with the human interface layout template (140-1) into an individual 
browser compliant human interface description (160); 

rendering (475) the individual browser compliant human interface description (160) to prompt an user for data 
input; 

receiving (480) data (1 70) from the user; 

storing (485) the data (170) in the data instance (150); and 

storing (490) a status of at least one basic layout element (122, 123, 124-1 , 124-2, 125, 126, 127). 

36. The computer program product (1 00) of claim 32, causing the computer (900) to execute the further step: 

decomposing (440) the standardized human interface description (1 20) into a human interface layout template 
(140-1) and a data description (140-2). 

37. The computer program product (100) of claim 36, causing the computer (900) to execute the further step: 

instantiating (460) a data instance (150) from the data description (140-2); 

merging (470) the data instance (150) with the human interface layout template (140-1) into an individual 
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browser compliant human interface description (160); 

rendering (475) the individual browser compliant human interface description (1€0) to prompt an user for data 
input; 

receiving (480) data (1 70) from the user; 
5 storing (485) the data (1 70) in the data instance (150); and 

storing (490) a status of at least one basic layout element (122, 123, 124-1 , 124-2, 125, 126, 127). 

38. A data carrier (970) readable by a computer (900) ; the data carrier (970) storing a plurality of instructions for-causing 
a processor (910) of the computer (900) to create and process a human interface description; the plurality of 

10 instructions causing the computer (900) to execute the method (400) steps of claims 1 , 6, 14 and 1 8. 

39. A data carrier (970) readable by a computer (900) ; the data carrier (970) storing a plurality of instructions for causing 
a processor (910) of the computer (900) to create and process a human interface description; the plurality of 
instructions causing the computer (900) to execute the method (400) steps of claims 1,10 and 22. 
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